This has been a disaster to test. First, after setting up a mocked CWS system and a custom docker image, and spinning up a test server using that hash, you can only upload the plugin once. After that the plugin upload button is deactivated (but you can get around that by never leaving the system console). Second, often you'll get an error back from uploading a plugin:

If you get that, your server is toast -- it will no longer accept plugin uploads, so you have to spin up a new one.

Third, the MAX_CALLS_MAX_PARTICIPANTS env var wasn't working at all. Finally figured out that OnConfigurationChange is getting called after the onActivate has set the overrides, which overwrites the config with the one from the system console. So 36c67f6 fixes that and lets us have permanent overrides. (FYI: This happens with on-prem servers as well.) But that means cloud customers cannot turn off default calls, which we probably don't want. So we have to find a way to make the setOverrides override the plugin default, but not once the user has changed it manually.

Fourth, I could not test whether the manual max participants configuration setting works in cloud, because it wouldn't let me change any config settings. It would respond with:

Finally, I could not test the max 8 default for cloud. This is because I could not change other settings like Enable Open Server because it responded with:

What I was able to test:

• with 36c67f6 the env var works correctly and is sent to webapp (and mobile) and the UI changes as expected.

What I was not able to test:

• changing the config setting in the system console works as expected (i.e., is transmitted to the clients and changes the limits and the UI as expected)
• that changing the config setting for default enabled in cloud is respected (it won't be, at the moment)
• that the cloud max of 8 participants was respected (the point above about not being able to change Enable Open Server)

Issues found:

• We should add the N/A cursor for the channel header button and channel header dropdown button.
• Config changes require the webapp and mobile to reload before they get the new config values, which means they'll try to join a call and get no response. I think this is probably "ok" for beta, but not later.

So at the moment I think we need to:

1. fix the Default Enable Calls setting override issue,
2. and then just to ship it and hope?
3. And then we need to get proper cloud freemium test servers with plugin uploads.

Thanks @cpoile ,

I am sorry you had to go through all that trouble just to test this but if anything it helped to reinforce even further the need to have better tools/permissions when testing/debugging in Cloud. I'll make sure to raise these concerns in our future discussions with Cloud/SREs.

For the sake of this PR could we test whatever is feasible using cloud licenses on a local env? I understand it won't be 100% accurate (as we have seen already) but it's better than nothing.

Third, the MAX_CALLS_MAX_PARTICIPANTS env var wasn't working at all. Finally figured out that OnConfigurationChange is getting called after the onActivate has set the overrides, which overwrites the config with the one from the system console.

Interesting, there must be some racy behaviour with the two operations then given that locally I was consistently getting the activation after the initial config change trigger. I am almost regretting not going forward with the plugin id change since it would have prevented all this 😬

Anyhow, I think for the time being we can put in place a little check and apply the overrides as soon as the configuration has been loaded the first time. E.g.:

func (p *Plugin) setConfiguration(configuration *configuration) error {
	p.configurationLock.Lock()
	defer p.configurationLock.Unlock()

	if p.configuration == nil && configuration != nil {
		setOverrides(configuration)
	}

What do you think?

Config changes require the webapp and mobile to reload before they get the new config values, which means they'll try to join a call and get no response. I think this is probably "ok" for beta, but not later.

Yes this is expected and fine for now. Created MM-44781.

We should add the N/A cursor for the channel header button and channel header dropdown button.

I think there may still be some issues with on-prem I guess where we should show the blocked cursor anyway since there's nothing to click but it's a minor thing.

No worries. :)

For the sake of this PR could we test whatever is feasible using cloud licenses on a local env? I understand it won't be 100% accurate (as we have seen already) but it's better than nothing.

I've done that, and that would be the "let's just hope" option. In the end I don't think there is a way to finish testing this at the moment, so it's the only option.

What do you think?

That won't work, unfortunately, because the pluginAPI isn't set at that point either.

I think that putting the overrides in the OnActivate works only when the server is started/restarted with the EnvVars. Which I can't test because this PR's plugin isn't in the prepackaged plugins list for a test server. I could try to make that happen, but that would be a lot of work.

Instead, when you upload a plugin, that's when the overrides in the OnActivate don't work, because the OnConfigurationChange is called once more after the OnActivate, and overwrites the OnActivate overrides.
Maybe this is not intended and it's a bug?

But either way, maybe we can keep it in the OnActivate and then just know that any time the plugin is updated (either manually, which isn't possible, right? -- or through the marketplace, which is possible, right?) the env var and defaultEnabled will be lost.

Done. Was able to test everything, including mobile. I wasn't able to test that changing the config setting in the system console doesn't affect the overrides, because of the error I talked about above. But I'm assuming so, b/c of the code.

I think we're good to go @streamer45

Thanks @cpoile for the huge effort here 💯